Fix network panel behind VPN policy routes - #8866

Independent confirmation on a wg-quick-managed full-tunnel WireGuard connection (not WARP/Tailscale), plus a before/after capture against the current script.

Environment

• Omarchy dev (86a2e583) / omarchy-dev 4.0.0.r2128.gb679363-1
• Kernel 7.2.4-arch1-2, NetworkManager 1.58.1
• Wi-Fi associated to an OWE-transition SSID; WireGuard tunnel AAM-WG with AllowedIPs = 0.0.0.0/0, ::/0 (owns the default route via table 51820)

Before (/usr/bin/omarchy-network-status --verbose, tunnel up):

iface   AAM-WG
ip      192.168.12.3
prefix  32
gateway
type    ethernet
cat: /sys/class/net/AAM-WG/speed: Invalid argument
speed
cat: /sys/class/net/AAM-WG/duplex: Invalid argument
duplex

After (this PR's bin/omarchy-network-status, same moment, tunnel still up):

iface   wlp5s0
ip      172.20.6.244
prefix  20
gateway 172.20.0.1
type    wifi
ssid    <redacted>-owe-tr
signal_dbm  -50
freq    5680.0
bitrate 286.7 MBit/s
router_ping_ms  1.45

The tunnel interface has no /sys/class/net/<iface>/wireless directory, so the
if wireless … else ethernet branch at the bottom of print_verbose classifies
it as ethernet, and the speed/duplex reads then fail with Invalid argument
because a WireGuard interface exposes neither. This PR's physical_device()
resolves it correctly.

One extra symptom worth recording: the bar icon and the panel's header text
are driven by different sources, so they disagree while a tunnel is up. The
text comes from info.type (this script, via detailsPoll), while the glyph
comes from kind in plugins/panels/network/Panel.qml, which is derived from
Quickshell's Networking.devices. The visible result is a header reading
"Ethernet" next to a Wi-Fi glyph, and because detailsPoll only runs while the
panel is open, the two drift in and out of agreement — which reads as the icon
flickering at random. Fixing the script's classification resolves the header
half; the glyph half is separate (Quickshell's DeviceType enum is
[None, Wifi, Wired], so a WireGuard device is reported as Wired and
Panel.qml's kind returns "ethernet" whenever a wired-type device is
connected).

A local workaround for the glyph half, for anyone hitting this before the
enum gains a VPN type:

# /etc/NetworkManager/conf.d/95-wireguard-unmanaged.conf
[keyfile]
unmanaged-devices=type:wireguard

wg-quick owns the interface anyway (NM only adopts it as
managed-type: 'external'), so marking it unmanaged costs nothing and stops
NM from racing the device through ~9 state transitions on every tunnel
up/down — each of which re-renders the bar icon.

Thanks for the independent repro on a wg-quick full tunnel. A policy-routed default on table 51820 is exactly the case physical_device() exists for, and your before/after captures line up with what it does: pick the active physical NetworkManager device, and only fall back to the main table's lowest-metric default when there is none.

On the second symptom, you split it correctly and I agree it is two halves. The header text comes from info.type (this script), so this PR settles that half — a WireGuard interface is no longer classified as ethernet, and the speed/duplex reads that failed with Invalid argument go away with it. The glyph is drawn from kind in plugins/panels/network/Panel.qml, which derives it from Quickshell's Networking.devices; with DeviceType being [None, Wifi, Wired] a WireGuard device reports as Wired, so the panel can draw an Ethernet glyph next to a Wi-Fi header. I would rather not fold that into this PR: the honest fix is for the panel to make the same physical-device decision the status helper now makes (or for Quickshell to expose a VPN type) instead of inferring it from the device type, and that deserves its own change and review.

Your unmanaged-devices=type:wireguard drop-in is a good stopgap — wg-quick owns the interface anyway, so keeping NetworkManager out of it costs nothing. If you are willing to open an issue on omacom/omarchy with the flicker description, that is where the glyph half belongs; I will link it here so the two are read together.

Thanks. Issue #10619 already tracks the false-disconnected Wi-Fi icon, so I added our observations there rather than create a duplicate: #10619 (comment)

One correction to my earlier comment: the full-fan/slashed-fan cycling continued after unmanaged-devices=type:wireguard and a shell restart. That workaround did not resolve the flicker. The helper test supports the header fix in this PR, not a fix or proven cause for the intermittent icon changes. We did not test the device-state fix proposed in #10619.

Reviewed against quattro at 8af95b5. The bug is real: ip route get 1.1.1.1 follows policy routing, so a Tailscale exit node, a wg-quick full tunnel or a Clash TUN makes the panel describe the tunnel as Ethernet, and @wundrellama's before/after above shows this branch fixing it for wg-quick.

Four other open pull requests fix the same bug: #12071, #13529, #13666 and #13808. I read all five against quattro, and of them #12071 looks like the one to bring forward, for two reasons that bear on this branch:

• physical_device() accepts only NetworkManager devices of type wifi or ethernet. When the uplink is a bridge or a bond, the first connected match is a port device with no address of its own (br0/bond0 are skipped), so the panel names the port and reports an empty IP. Show physical network behind TUN routes #12071 walks the main table's default routes and skips only tun and wireguard devices, so bridges, bonds and modems keep working.
• When both Wi-Fi and Ethernet are up, the choice here rests on the order of nmcli dev status. That is the device holding the default route in the common case, but nmcli sorts a shared (hotspot) connection ahead of it, and when a NetworkManager VPN holds the default route the physical devices are ordered by how many addresses they have (nmc_active_connection_cmp in NetworkManager's src/nmcli/connections.c). Show physical network behind TUN routes #12071 takes the kernel's own lowest-metric order instead, as the base script did.

#13529 and #13808 read only the main table's default, so a NetworkManager VPN that installs its own default there (metric 50) is still shown as the uplink. #13666 also adds a vpn type and touches the panel, which is more than the bug needs.

Nothing was run on a worker for this branch, since it is not the fix I would bring forward. The second opinion (Codex Medium) did not run: its daily review budget was spent when this was checked, so this comparison is one model's reading and has not been checked by a second. Waiting on the maintainer to choose between the competing fixes.

Follow-up to the review above, at the same head (8af95b5), now with the second opinion that was missing then. #13808 has since closed, so three other open pull requests fix this bug: #12071, #13529 and #13666.

Codex Medium was asked which fix to bring forward, without being given my answer, and it also chose #12071. Independence is not guaranteed, since the earlier comment here was public. It found the same bridge/bond defect in this branch: with the uplink on br0 or bond0, physical_device() takes the first connected port of type ethernet, which has no address of its own, so the panel shows an empty IP and borrows the master's gateway. quattro shows the master and its address correctly today. Codex also found a defect I had not reasoned about. Because the choice follows nmcli dev status order instead of route metrics, a connected LAN-only Ethernet port can hide a modem or USB tether that actually carries the default route, since only Wi-Fi and Ethernet devices are looked at before the fallback.

Codex also named limits in #12071 that its author can work on separately: an uplink nmcli does not know is skipped, and the source lookup has no address fallback. The fallback is the one thing this branch does better. Neither changes which fix to bring forward. #13529 and #13666 read only the main table's default route, so a NetworkManager VPN that installs its default there is still shown as the uplink. #13666 also labels a raw-IP QMI modem as a VPN.

Nothing was run on a worker for this branch, since it is not the fix that would be brought forward. Waiting on the maintainer to choose between the competing fixes.